اگر با مدیران استخدامی شرکتها گفتوگویی داشته باشید، مشاهده میکنید که بسیاری از این افراد مشتاق هستند تا مهندسان دواپس را استخدام کنند. در حالی که تعدادی از این مدیران استخدامی با واژه فوق آشنایی دارند، اما در مقابل تعداد دیگری هیچگونه آشنایی با این واژه ندارند. بسیاری از این افراد کنجکاو هستند تا بدانند اساساً یک مهندس دواپس قادر به انجام چه کارهایی است؟ اما پیش از آنکه به کارهایی که یک مهندس دواپس قادر به انجام آنها است اشارهای داشته باشیم، ابتدا باید تعریفی برای این واژه ارائه کنیم. دواپس از ترکیب دو واژه Development بهمعنای «توسعه نرمافزار» و OperationS بهمعنای «عملیات فناوری اطلاعات» تشکیل شده است. دواپس یک فرآیند تولید نرمافزار است که بر ارتباط و همکاری هرچه بیشتر تیمهای توسعه نرمافزار با تیمهای اجرایی تمرکز و تأکید دارد. این فرآیند بهدنبال آن است تا عملیاتی همچون یکپارچهسازی، آزمایش، استقرار و یک سری تغییرات بنیادین را خودکارسازی کند. در حالت کلی، دواپس بهدنبال ایجاد فرهنگ و محیطی است که در آن تولید، آزمایش و انتشار نرمافزار بهشکلی سریع، مستمر و قابل اطمینان به سرانجام برسد.
برای آنکه درک بهتری از این مفهوم داشته باشید و بدانید یک مهندس دواپس به طور دقیق قادر به انجام چه کارهایی است، ابتدا باید چرخه تولید نرمافزار را مورد بررسی قرار دهید. محصولات نرمافزاری کوچک و بزرگی که روزانه مورد استفاده قرار میدهید، پس از گذراندن یک چرخه پنج مرحلهای آماده میشوند و به دست شما میرسند. این پنج مرحله عبارتند از برنامهریزی (Planning)، توسعه (Development)، آزمایش (Testing)، استقرار/ انتشار (Deployment) و درنهایت نگهداری/ پشتیبانی (Maintenance) که در این میان دو مرحله برنامهریزی و نگهداری بخش عمدهای از وقت مهندسان دواپس را از آن خود میکنند. (شکل 1)
شکل 1
مرحله برنامهریزی
در اولین مرحله که بهنام برنامهریزی یا طرحریزی معروف است، اعضای تیم متشکل از توسعهدهندگان، مدیران تولید و... چشماندازها و اهداف پروژه را تعریف و قالب کلی نرمافزار را مشخص میکنند. در این مرحله، وظیفه مهندس دواپس این است که از دانش فنی اعضای تیم و تسلط اعضا بر زیرساختها و چهارچوبهای موجود استفاده و این موضوع را ارزیابی کند که چگونه میتوان در قالب یک سیستم جامع و یکپارچه به تمام چشماندازها و اهدافی که تیم بهدنبال آنها است دست پیدا کرد. زمانی که سیستم اولیه پیادهسازی شد و به مرحله اجرا درآمد، باید این موضوع مورد بررسی قرار گیرد که چگونه تیم میتواند فناوریها یا مؤلفههای از پیش ساخته را با سامانه موجود یکپارچه کند. برای آنکه این کار به بهترین شکل ممکن به سرانجام برسد، ممکن است به برنامهریزی دقیقی برای بهکارگیری این مؤلفهها و اجرای خودکار آنها نیاز داشته باشید. در این مرحله مباحث دیگری همچون نحوه استقرار بانک اطلاعاتی جدید و پشتیبانی از ریزسرویسهای زیرساختی جدید در سامانه اولیه مورد بررسی قرار میگیرد. مباحثی همچون نگهداری و خودکارسازی نیز در این مرحله مورد بررسی قرار میگیرند. در واقع، مهندس دواپس در این مرحله و در اغلب موارد بهدنبال پیدا کردن روشهایی برای خودکارسازی فرآیندهای مختلف است، این خودکارسازی به میزان قابل توجهی فشار وارد شده به تیم را کم میکند. در این مرحله مهندس دواپس بهدنبال پاسخی برای پرسشهای زیر است:
- دو سرویس متفاوت چگونه میتوانند با یکدیگر تعامل برقرار کنند؟
- برای برقراری ارتباط میان دو سرویس از چه پروتکلی باید استفاده کرد؟
- آیا سختافزارهای موجود پاسخگوی نیاز ما خواهند بود یا بهتر است از سرویسهای کلاود برای تحقق این امر استفاده شود؟
- برای آنکه بتوانیم در مرحله تولید به مهندسان/ کدنویسان کمک کنیم باید چه پارامترهایی را مورد توجه قرار دهیم؟ سرویس آماده به تولید چیست؟
- چگونه میتوانیم از تمام نرمافزارهای موجود برای پیشبرد هرچه بهتر کار استفاده کنیم؟
- آیا این امکان وجود دارد تا تمام وابستگیهای مورد استفاده در نرمافزار را کنترل کرد و آیا درک ما از این عوامل به اندازه کافی جامع است که بتوانیم در زمان بروز مشکلی به اشکالزدایی از آنها بپردازیم؟
- چه مؤلفهای را باید ایجاد و چه مؤلفهای را باید خریداری کنیم؟
- این امکان وجود دارد تا وظیفه خاصی را خودکارسازی کرد؟ در آینده چگونه میتوانیم از نرمافزار طراحی شده پشتیبانی کنیم؟
مرحله توسعه
در مرحله توسعه نرمافزار، ترکیب کلی کار مشخص شده و اکنون زمان آن رسیده است تا توسعهدهندگان کار کدنویسی را آغاز و ویژگیهای از پیش تعیین شدهای که قرار است به محصول وارد شوند را ایجاد کنند. در این مرحله مهندس دواپس بهدنبال راهکارهایی است تا این وظایف را به بهترین شکل و کمترین زمان ممکن به سرانجام برساند. این رویکرد دقیقاً با چشمانداز نهایی کار که همانا تولید نرمافزار است در هماهنگی کامل قرار دارد. مهندس دواپس به طراحان اعلام میدارد از چه ابزارهایی استفاده کنند و ابزارهایی که توسعهدهندگان به آن نیاز دارند را در اختیارشان قرار میدهد. یکی دیگر از وظایف مهندس دواپس این است که بخشهای مختلفی از کدها که از سوی طراحان در
محیط توسعه نوشته شده است را دریافت کرده و این قطعات را در کنار یکدیگر قرار داده و این مؤلفهها را با محیط/ خروجی نهایی نرمافزار هماهنگ سازد. این وظیفهای نیست که بتوان آن را به عهده طراحان واگذار کرد. امروزه اگر مهندسان دواپس در شرکتهای مختلف حضور نداشتند، ما قادر نبودیم از نرمافزارهای مطرح و شاخص استفاده کنیم. (شکل 2) سؤالاتی که یک مهندس دواپس در این مرحله باید بهدنبال پاسخگویی به آنها باشد به شرح زیر است:
چگونه باید طراحان را در محیطی مشابه با محیط محصول نهایی نگه دارم و در همین راستا به آنها اجازه دهم تا از ابزارهایی که به آنها علاقه دارند یا در آن تخصص دارند استفاده کنند؟ چگونه میتوانم عملکرد طراحان را بهشکل مطلوبی افزایش دهم؟ چگونه میتوانم برای طراحان توضیح دهم که در حال کدنویسی برای چه محیطی هستند و محیط نهایی نرمافزاری که آماده خواهد شد چگونه خواهد بود؟
شکل 2
مرحله آزمایش
در مرحله آزمایش، طراحان و افرادی که مسئول کنترل کیفیت هستند کدهای نوشته شده را مورد آزمایش قرار میدهند و این کدها را بهمنظور ادغام با سورس کد اصلی آماده میکنند. در این مرحله ممکن است از اسکریپتها و ابزارهایی بهمنظور انجام خودکار آزمایشها استفاده شود. با وجود این، برای اجرای دستی بعضی از کدها روی سامانههای داخلی شرکت به حضور فیزیکی طراحان و مسئولان کنترل کیفیت نیاز است. البته این احتمال وجود دارد که محصول نهایی در این مرحله مورد آزمایش قرار گیرد یا کدهای نوشته شده در یک محیط شبیهسازی شده مورد آزمایش قرار گیرند. به طور معمول، در این مرحله کدها بهشکلی سریع اجرا میشوند یا بهمنظور تطابق بیشتر از سامانههای مشتری برای آزمایش کدها استفاده میشود. مهندس دواپس باید سناریوهایی که به آنها اشاره شد را مد نظر قرار دهد و در عین حال به فکر اجرای خودکار آزمایشها نیز باشد. مهندسان دواپس ابزارهایی همچون Jenkins، Bamboo یا Drone را برای خودکارسازی آزمایشها در اختیار دارند. این ابزارها که در اصطلاح رایج به آنها CI (سرنام Continuous Integration) نیز گفته میشود، قادرند فرآیند آزمایش کدها را بیش از پیش ساده سازند. همچنین، یک مهندس دواپس باید بهدنبال پاسخی برای پرسشهای زیر باشد:
بر مبنای چه راهکاری میتوان محیطهای کاربری تکرارپذیر را طراحی کرد؟ بر مبنای چه معیاری اطلاع پیدا کنم آزمایشهای انجام شده در ارتباط با کدام نسخه از سرویس یا محصول به مرحله اجرا درآمده است و مهمتر از آن درست بودهاند؟ بر مبنای چه راهکاری باید تاریخچه مربوط به آزمایشها را بررسی و روندهای فعلی را ارزیابی کنم؟ چگونه میتوانم پس از آزمایش کدها مشکلات را به طراحان اعلام دارم؟ دادهها و اطلاعات مربوط به آزمایشها را از چه منبعی باید به دست آورم؟
دواپس از ترکیب دو واژه Development بهمعنای «توسعه نرمافزار» و OperationS بهمعنای «عملیات فناوری اطلاعات» تشکیل شده است. دواپس یک فرآیند تولید نرمافزار است که بر ارتباط و همکاری هرچه بیشتر تیمهای توسعه نرمافزار با تیمهای اجرایی تمرکز و تأکید دارد. این فرآیند بهدنبال آن است تا عملیاتی همچون یکپارچهسازی، آزمایش، استقرار و یک سری تغییرات بنیادین را خودکارسازی کند.
شکل 3
مرحله استقرار
این مرحله بهمعنای استقرار و توزیع کدها در محیطی است که درباره بحث ما سرور اصلی نرمافزار است. در مرحله استقرار این موضوع مورد بررسی قرار میگیرد که کدهای نوشته شده چگونه و با چه نظمی باید در محصول نهایی وارد شوند و کدام کدها باید در سمت کاربر نهایی به مرحله اجرا درآیند. یک مهندس دواپس از ابزارهایی مشابه با ابزارهای CI (خودکارسازی آزمایشها) برای خودکارسازی این جریان استفاده میکند. در این مرحله نیز یک مهندس دواپس باید بهدنبال پاسخگویی به پرسشهای زیر باشد:
در چه بازه زمانی یک نسخه آماده شده از نرمافزار را باید مستقر کرد؟ چگونه میتوانم بدون اطلاع مشتری سرویسی را مستقر کنم؟ از چه راهکاری باید استفاده کنم تا مطمئن شوم سرویسی که بهتازگی مستقر کردهام، در کار سایر سرویسها اختلال ایجاد نمیکند؟ در مدت زمان استقرار خودکار چگونه میتوان یک سری از مراحل را بهشکل دستی و غیرخودکار مستقر کرد؟ بر مبنای چه راهکاری میتوان فرآیند استقرار را با رویکردی تکرارپذیر انجام داد؟ در مقایسه با مراحلی که به آنها اشاره شد، مرحله استقرار زمان قابل توجهی از وقت مهندسان دواپس را به خود مشغول نمیکند. در مقابل مرحله نگهداری همان گونه که مشاهده خواهید کرد، زمان قابل توجهی از وقت مهندسان دواپس را میگیرد.
مرحله نگهداری
همان گونه که در پاراگراف قبل به آن اشاره کردیم، مرحله نگهداری نرمافزار از جمله مراحلی است که بخش عمدهای از وقت مهندسان دواپس را به خود مشغول میکند. اگر تاریخچه شرکتهای بزرگی همچون گوگل را مورد بررسی قرار دهید، مشاهده میکنید که یک جایگاه شغلی تنها با هدف نگهداری در این سایت بهنام Site Reliability Engineering در نظر گرفته شده است. مهندسان این بخش بر این باورند، وظیفهای که به آنها محول شده است درست همانند وظیفهای است که تعمیرکاران بخش ماشینهای مسابقه عهدهدار آن هستند و شما در میانه مسابقه اتومبیلرانی قرار دارید که ماشینها با سرعت 150 کیلومتر بر ساعت در حرکت هستند و اکنون در نظر دارید تایر این ماشینها را تعویض کنید. مرحله نگهداری در ارتباط با انجام وظایفی است که در انتها یک سامانه را در دسترس قرار میدهد و کارایی آن را نیز حفظ میکند. در این مرحله یک مهندس دواپس باید بهدنبال پاسخی برای پرسشهای زیر باشد: (شکل 3)
بر مبنای چه راهکاری قادر خواهم بود ایرادات و اشکالهای موجود در سرویس یا محصولی را شناسایی کنم؟ بر مبنای چه راهکاری باید خطاهای موجود در محصول یا سرویسی را به تیمهای مربوطه اعلام دارم؟ بر مبنای چه راهکاری باید اشکالهای موجود در زیرساخت یک محصول را برطرف کنم؟ مهندسان چگونه اشکالات شناسایی شده در سرویسها را برطرف میکنند؟ من بهعنوان یک مهندس دواپس بر مبنای چه راهکاری باید از درست کار کردن یک سرویس اطمینان حاصل کنم؟
درنهایت
همان گونه که ممکن است حدس زده باشید، وظیفهای که یک مهندس دواپس عهدهدار آن است در واقع مشتمل بر وظایف چندگانه است. به طوری که درنهایت یک مهندس دواپس باید بتواند طراحان و مهندسان اجرایی را بهشکلی نظاممند در کنار یکدیگر قرار دهد. در مجموع دواپس حلقه گمشدهای میان اجرای کدها بهصورت مستقل و اجرای آنها در نرمافزار یا سرویس نهایی است. ارنست مولر فارغالتحصیل رشته مهندسی برق دانشگاه رایس و سازماندهنده کنفرانس DevOpsDays در آستین تگزاس در ارتباط با دواپس میگوید: «بهتر است دواپس را یک تحویل و عملیات چابک نرمافزاری (Agile Software Delivery and Operations) توصیف کنیم. رویکردی که در آن افراد از طریق همکاری و مشارکت با یکدیگر روی ایدههای بزرگ سازمانی کار میکنند، بدون آنکه ارزش پیشنهادی اصلی خود را به دست فراموشی بسپارند.»
به این مطلب چند ستاره میدهید؟(امتیاز: 4.3 - رای: 2)
- منبع: ماهنامه شبکه
- نویسنده: حمیدرضا تائبی